Software Communications Architecture (SCA) is a standardized communications software architecture proposed to greatly enhance interoperability between communications systems and reduce a cost for research and deployment by Joint Tactical Radio System (JTRS) Joint Program Office (JPO) of the United States. The SCA guarantees portability and configurable capability of software and hardware devices and guarantees interoperability between products which are built upon the SCA. The SCA employs, as middleware, adopting Common Object Request Broker Architecture (CORBA) of an industry standard of an object model to provide the infrastructure for various hardware device and software to work together. The SCA is an independent system design framework, not limited to a specific system. An SCA-based system is a communication system built upon the SCA. For example, a Software Defined Radio (SDR) system has adopted the SCA as a standard of a software framework. The application in the SCA performs functions of a single waveform. Therefore, several components are assembled in a single package to be installed, deployed, and implemented.
The relation of the conventional SCA and a waveform application will be described with reference to FIG. 1, below:
As shown in FIG. 1, in the SCA system, Operating System (OS) 102, CORBA 103, and SCA Core Framework (CF) 104 are arranged above hardware devices 101 such as a Central Processing Unit (CPU), a Digital Signal Processor (DSP), and a Field Programmable Gate Array (FPGA). With domain profiles 105 in the SCA CF 104, various managers of the SCA CF 104 arrange the components 110 of the upper waveform application 109 in related hardware devices to implement. The components of the waveform application communicate with each other by transmitting and receiving information through the ports which is defined in the SCA system for the respective communications. The managers may be a domain manager 106, a device manager 107, a file manager 108, an application factory 201, and the like.
In the SCA aforementioned, when the SCA-based application 109 is running, the components 110 included therein can transmit and receive data through connection set by the application factory 201 for generating an application, by using connection information, included in the domain profiles 105, on a pair of the ports, i.e., an input port (InPort) and an output port (OutPort) connecting a couple of the components. The connection information defined in terms of the InPort and the OutPort is required to be set between all of the components which need to communicate in a single application. Further, in the SCA, the connections are required to be defined as simplex communication. The connection information on the connections between the components and on the ports is managed by defining in the XML file.
A process of running the waveform application in the conventional SCA structure as afore mentioned will be described with reference to FIG. 2.
As shown in FIG. 2, in the conventional SCA structure, all information of a corresponding waveform application is defined in the domain profiles 105 in the XML file format, and the domain profiles 105 are referred when the application is running.
Therefore, the application factory 201 generates the waveform application X by interpreting the information included in the domain profiles 105, and the waveform application X 202 internally performs management of an assembly controller 203 and components, e.g., component A 207 and component B 208.
The assembly controller 203 transmits control information to the component through a control port such as A_ControlPort (ACP) 204a or B_ControlPort (BCP) 204b. Further, in the SCA, the assembly controller 203 and all of the components are registered in a naming server 209 of the CORBA 103. All the components can find the components for communication by retrieving the registered information, and communicate with each other based on it.
The ports of each component in the SCA, however, are controlled by each component internally, without being registered in the naming server 209.
Each component has the connection information in order to communicate with the other component and the connection information is defined as simplex communication. For example, when the component A 207 needs to send information to the component B 208, the component A 207 sent the information to A_OutPort 209b according to a definition in connection 1 where the A_OutPort 209b is previously defined to be connected with B_InPort 210a. As a result, the information sent through the A_OutPort 209b is transmitted via the B_InPort 210a of the component B 208, thereby the component B 208 receiving the information.
In other words, when the conventional SCA-based application initiate to run, the application factory 201 parses the connection information defined in terms of the InPort and the OutPort in the domain profiles (XML files) 105, and then transmits the connection information to each component when the SCA-based application is running.
Based on the connection information, each component can communicate with each other by transmitting data through OutPort Object Reference which corresponds to an output port in connection with the other component for communication.
In the conventional domain profiles, however, there is no definition of priority order of the ports of the component when the component communicates with others through the ports so that it is impossible to control the priority of the ports. That is, when data is received through a port while another port is performing a job, the received job through the port cannot be started until the end of the preceding job which is being performed. Therefore, in the SCA in which the application is a protocol stack of a mobile communication network, protocol control information and data information are different in priority but cannot be differentiated. As a result, the conventional SCA cannot provide the quality of service (QoS) demanded in mobile communication services.